In telecommunications signaling networks, it is often necessary to count the number of signaling messages that match user-specified criteria. For example, for usage measurements or billing purposes, it may be necessary to count the number of messages of a particular type originating from a particular source and/or being sent to a particular destination. In order to keep track of such counts, network operators define accumulators in hardware or software associated with signaling link monitoring systems. These accumulators are referred to as peg counters. Each peg counter has a definition and an associated accumulator value. The definition specifies rules for incrementing the accumulator value. For example, the definition may specify that the accumulator value is to be incremented based on detection of messages of a user-specified type and having user-specified parameter values. The accumulator values are also referred to as peg counts.
Conventionally, peg counts have been generated using signaling link probes and software that is hard-coded to generate the peg counts that a particular service provider desires to obtain. In such systems, if the service provider desires to add or change the peg counts being generated, peg count generation must be stopped, the peg count generation software must be modified, and the software must be recompiled and re-loaded into memory of the computer performing the peg counting. Some conventional systems provide a user interface for modifying peg count generation. However, even these systems require that peg counting be stopped while the changes are made. In addition, conventional user-configurable peg count generation systems require that peg counter definitions be specified completely using binary or hexadecimal values, which requires expert knowledge of signaling message parameter fields.
Another problem associated with some conventional peg count generation systems is that peg counts are generated at a central location, rather than at message collection locations. As a result, entire messages must be sent across a service provider's internal network. Sending copies of all monitored messages across a service provider's network consumes bandwidth and reduces bandwidth available for other services. In addition, aggregating messages at a central location before generating peg counts greatly increases peg count generation time, because the peg counter application must process messages from all of the message collection locations to create each peg count.
Accordingly, there exists a need for improved methods and systems for defining, modifying, and activating signaling message peg counters.